home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 25 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.7 KB

  1. Path: in2.uu.net!bounce-back
  2. Date: 10 Jan 96 08:19:26 GMT
  3. Approved: fjh@cs.mu.oz.au
  4. From: jason@cygnus.com (Jason Merrill)
  5. Newsgroups: comp.std.c++
  6. Subject: string implementation (was: ANSI/ISO Exception Hierarchy)
  7. X-Original-Date: 09 Jan 1996 12:54:37 -0800
  8. Organization: Cygnus Support, Mountain View, CA
  9. Message-ID: <u9ohsdozqq.fsf_-_@yorick.cygnus.com>
  10. References: <4cgog4$jsq@netlab.cs.rpi.edu> <4cipio$pcj@netlab.cs.rpi.edu>
  11.     <4crabd$91f@netlab.cs.rpi.edu> <4cteo4$32o@netlab.cs.rpi.edu>
  12.     <KANZE.96Jan9165545@slsvewt.lts.sel.alcatel.de>
  13. In-Reply-To: kanze@lts.sel.alcatel.de's message of 09 Jan 1996 15:55:45 GMT
  14. X-Newsreader: Gnus v5.0
  15. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  16.     iQBFAgUBMPN2uuEDnX0m9pzZAQGTEAF/Z1xgdNLccYZgOmcI0l9iqNB8iphoX0fj
  17.     JEZDB8hO6RXUvJN4YR67WEAlab/s5Qi/
  18.     =2TNg
  19.  
  20. >>>>> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
  21.  
  22. > In article <4cteo4$32o@netlab.cs.rpi.edu>
  23. > Etay_Bogner@mail.stil.scitex.com (Etay Bogner) writes:
  24.  
  25. > |> I believe that the string class would best implememnted as a
  26. > |> copy-on-change class, which means that the copy-constructor will not
  27. > |> actually duplicate the string but will increase the reference counter it
  28. > |> uses.
  29.  
  30. > I don't believe that copy on write is allowed in the current draft.
  31. > Each string can have its own unique allocator; how do you implement
  32. > copy on write in such cases?
  33.  
  34. I don't see why specifying the allocator would have any effect on COW.
  35. Whether a representation can be shared is independent of what method was
  36. used to allocate the storage for that representation.
  37.  
  38. > Even if copy on write were allowed, I can think of many reasonable
  39. > implementations in which string::data() (or string::c_str()) may throw
  40. > bad_alloc.  Maintaining the physical data internally as a contiguous
  41. > buffer makes most of the string manipulation functions relatively
  42. > expensive on long strings.  (Since I only use very short strings, this
  43. > doesn't bother me.  But it is a point that an implementor may want to
  44. > consider.)
  45.  
  46. I was going to tell you that the types of the iterators precluded any other
  47. representation, but happily it looks like that was changed in the September
  48. WP: from
  49.  
  50.       typedef typename Allocator::types<charT>::pointer        iterator;
  51.       typedef typename Allocator::types<charT>::const_pointer  const_iterator;
  52.  
  53. to
  54.  
  55.       typedef implementation_defined                      iterator;
  56.       typedef implementation_defined                      const_iterator;
  57.  
  58. This also gives COW implementations more flexibility.
  59.  
  60. Jason
  61. ---
  62. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  63.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  64.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  65.